Bad actors and cyber-attackers create malicious websites that install malware onto or otherwise attack a user's machine (whether that machine is a PC, Mac, tablet, phone, virtual-reality headset, augmented/mixed reality headset, or other computing device). These attackers can infect a user's machine at many levels, including taking advantage of security holes in operating systems and applications interfaces to system resources and drivers. One solution has been to restrict a user's direct access to the interface to the operating system (the “desktop”) from which applications are run and to “remote” the desktop so that it runs in a protected space (e.g., a sandbox or virtual machine) on a server computing system. There are many protocols for forwarding input from the client computing system to the remote desktop and for sending back the output from the remoted desktop application, including Remote Desktop Protocol (RDP) and other similar protocols, all of which communicate output from the remote desktop by sending pixels or video. One difficulty with RDP and similar protocols is that they are specific to desktop operating systems and will not provide an ideal user experience with a web browsing session because the desktop input and output is intercepted at the interface to the underlying operating system. In addition, they may rely on specific operating system services and drivers being present on a client device. For example, RDP assumes a client device supports GDI (a WINDOWS® operating system graphics device interface) which may not be available on non-Windows based devices and other less ideal graphics interfaces are used for those non-Windows based devices. Another difficulty is that they are limited to transfers of pixels (as bitmaps) when remoting to non-Windows operating system clients. Another solution has been to isolate applications on the client computing system in a sandbox such as a virtual machine or equivalent on the client machine itself. However, a disadvantage is that, should an attack somehow escape the sandbox, it can attack the entire client computing system where it is likely to have personally identifiable information linked to the user rather than a remote server. Another disadvantage is that client-side isolation may require installing software on the client computing system.
Additionally, exploits within web browsers provide many avenues for attackers to steal information, gain access, or install malware to a user's machine (whether that machine is a PC, Mac, tablet, phone or other computing device). For example, malicious code can take advantage of a flaw or vulnerability in the operating system or browser software to breach browser security. Active content in today's browsers, such as through use of Flash and/or JavaScript, contributes to browser vulnerability by enabling attackers to identify memory locations, scrape data, and generate malicious code. For example, an exploit might change browser settings without the user's knowledge, or even run arbitrary code by exploiting flaws in the many technologies that execute within the browser, such as HTML, JavaScript, CSS, Java, images, video, etc. As another example, websites can be injected with malicious code which results in ‘clickless’ infections by which malware is downloaded without requiring the user to do anything but visit the website. This downloaded malware may then steal credential information, effect identify theft, etc. Most problems caused by such attacks are treated “ex post facto” and cannot be prevented in total.
One manner of securing an application is to execute the application remotely on a server instead of locally on a client device where the hosted remoted application can be protected inside of a sandbox, such as a virtual machine. When the application is a web browser, this is sometimes referred to as “browser isolation.” One difficulty with using this approach with web browsers is that such browsers require extensive CPU, GPU, and memory resources making them expensive to run on a server.
Several attempted solutions have been employed to address these obstacles and to allow web browsers to be isolated by running them as remote processes. One such solution is to employ “pixel pushing” or “pixel mirroring” which allows a web page to be rendered remotely utilizing a web browser running on an external server to execute any active code associated with the web page and to produce a series of images which are sent back to a client web browser as compressed pixels or video (using for example H264 video format) to be eventually rendered by the web browser on the client device. This approach suffers from high bandwidth usage for sending pixel data, high server cost due to video rasterizing and encoding, high latency in the user experience, and rendering artifacts due to use of lossy compression or video encoding. In addition, malicious code can still penetrate the output sent to the endpoint (client) by changing pixels to embed malicious code to send bad data.
Another solution is to employ “Document Object Model” (DOM) remoting/mirroring. With this solution, the DOM corresponding to a page is sanitized before it is sent to the client to remove potentially malicious code and reconstructed on the client before rendering. This solution yields typically better performance than pixel pushing, but provides a less secure environment. Using DOM mirroring, a sanitizing process on the isolated browser computing system (e.g., a server) identifies bad HTML and active content and cleans up the DOM tree and reformats it without the active content or with content that has been transcoded into a safe format. Since the DOM on the isolated browser (the server) includes HTML, JavaScript, etc., malware still has plenty of opportunities to embed itself and surface. DOM mirroring also fails to support dynamic content (for example, WebGL or Flash), and each browser type renders DOM content differently, which leaves users with inconsistent or unpredictable experiences. Some companies offer solutions that allow a user, such as an IT administrator, to choose how much security is desired versus performance and employ a choice of using DOM mirroring and pixel pushing.
One approach to providing an isolation session is to have a web browser application executing on a client computer device download and parse a web application (for example, an application served via HyperText Transfer Protocol (HTTP) or HTTP Secure (HTTPS) and composed largely of HyperText Markup Language (HTML), JavaScript, Cascading Style Sheets (CSS), WebAssembly, or other components) to interface with a remotely isolated web browser instance to locally render outputs of the remotely isolated web browser instance as discussed above and to provide the remotely isolated web browser instance notifications of certain user inputs that are perceivable by the web application. Each of those user inputs must first be processed by the local web browser before being provided to the web application for use. Output of the remotely isolated web browser instance must be processed by the web application before being provided to the local web browser for rendering as discussed above. Accordingly, this approach often provides slow startup times and slow execution times.
Web applications also have limited access to the client computing device, such as fonts, a clipboard buffer, display details (for example, vertical blanking interval), or other limited aspects. This approach also causes locally installed extensions to operate on the web application yet not the remotely isolated web browser instance. For example, a local password manager extension would fail to recognize output of the remotely isolated web browser instance as including a password field that could be filled, unless the web application generated its own password field, which increases complexity. Moreover, many web browser functions that the user would expect to be available during non-isolation session are either not available or not seamless to the user during isolation sessions. For example, a find function of the local web browser searches the web application, which merely displays visuals from the remotely isolated web browser instance in a way that is not text-searchable (unless it is DOM mirroring, which is not fully secure, as discussed further above). As another example, a print or save function typically prints or saves output of the locally installed web application, instead of the output of the remote web browser. Some web browsers such as Chrome provide limited support for isolation sessions as utilized by the “devtool” views (for example, to view an Android browser), yet this limited support fails to seamlessly integrate into the existing user interface of the browser (for example, instead creating a separate input for an address bar of the remotely isolated web browser instance). This limited support also typically has limited features, as discussed further above.